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METHOD AND DEVICE FOR CREATING AND USING 
PRE-INTERNALI2ED PROGRAM FILES 

Field of the Invention 

5 

This invention relates generally to processing of program 
files written in a high-level language, and specifically to program 
flies written in a high-level programming language capable of 
dynamic loading. 

10 

Related Art 

As the number and type of hand-held and other electronic 
devices Increases, there is a corresponding increase in the 
applications that run on and interface with these devices, as well 

15 as an increase in the desired flexibility for the user to add special 
programs and functionality. These devices are sometimes 
referred to as "embedded devices," as they include a processor 
for executing instructions, special function units, and the 
instructions for providing the desired functionality. Embedded 

20 devices are typically stand alone devices, having their own 
power supply, but often include the capability to interface with 
other systems. For example, embedded devices such as 
cellular phones, pagers, and personal digital assistants (PDAs) 
typically include a central processing unit (CPU) for executing 

25 computer programs stored within the device and a battery 
allowing mobility. Subsequent to manufacture of an embedded 
device, individual users may desire to customize their device by 
adding special functionality or applications, it is desirable to use 
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computer programs, or codes, written in a hfgh-level 
programming language, such as Java™, a language developed 
by Sun Microsystems, Inc., which facilitates the later installation 
of user-supplied applications. Java is particularly attractive, as It 

5 is platfomi-lndependent, meaning that it is not specific to one 
operating system or hardware configuration. 

One constraint in developing code for an embedded 
device is the limited amount of memory, which reduces the 
amount of code that a device is able to store and also impacts 

10 the computing capabilities of the device. A key goal in designing 
code for an embedded device is then to maximize the memory 
efficiency and speed of Installed applications. Cun'ently, several 
methods of increasing the memory efficiency of embedded 
applications exist, however, these methods do not generally 

15 extend to the subsequent installation of additional applications 
by the user. 

Java In particular, is an object-oriented programming 
language that is portable, easy to program, and architecture- 
neutral. Object-oriented design focuses on the data, referred to 

20 as "objects," as well as the interfaces to the objects. The Java 
program is able to execute anywhere within a network including 
a variety of processing units and operating system architectures. 

Java programs are both compiled and interpreted. 
Compilation is done once, where compiled Java programming 

25 code is referred to as "Java ByteCode" (JBC). The JBC is an 
intermediate language that is architecture-neutral or platfomn- 
Independent. A Java interpreter parses and runs JBC 
instructions on a processor. Interpretation occurs each time the 
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program is executed. A Java binary file, referred to as a class 
file, includes the JBC for a given program as well as supporting 
information, such as symbolic data. A class file, or program file, 
includes "items" or information about the class, such as fields, 
5 methods, JBC arrays, and a symbolic reference table. 

Specifically, a Java program Is composed of one or more Java 
files, which, on compilation, produce one or a set of class files. 

JBC is effectively the machine code instructions for a 
"Java Virtual Machine" (Java VM). Every Java interpreter, such 

10 as a Java development environment or a Java-capable web 
browser, uses an Implementation of the Java VM. Often, these 
tools will either use the Java VM already installed on a system, 
or may come bundled with a Java VM. Note that the Java VM 
may also be implemented in hardware. In this way, the program 

15 may be compiled on any machine with a Java compiler and the 
resulting JBC may run on any Implementation of the Java VM. 

In order to make applications written in Java portable, 
much symbolic information Is maintained. During normal Java 
VM execution of the JBC, the symbolic data is used by the Java 

20 VM to perform the dynamic binding whereby the actual pointer to 
the referenced structure is obtained. For example, each 
reference to a function is represented by the symbolic 
information: class name; function name; and signature. The 
class name identifies the class object containing the declaration 

25 of the method. The methods identify the various functions 
available for that class, and the JBC arrays are programs 
executed to Implement a method. The function name, together 
with the signature, identifies the given function within its class. 
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The signature describes the member and type of arguments 
passed to and returned by a function. The symbolic information 
expands the size of the Java binary file and that expansion 
creates nnemory storage problems. During execution, two (2) 

5 copies of the JBC and the symbolic information are maintained: 
a first copy is stored in permanent memory; and a second copy 
is stored in dynamic memory in a format easily manipulated by 
the Java VM. For small, embedded devices, such as pagers, 
cellular phones, and PDAs, dynamic memory is very limited. It 

10 is, therefore, desirable to reduce dynamic memory usage. An 
additional problem is latency during execution due to the use of 
costly table lookups for handling symbolic references. 

To address some of these problems, tools allow for 
compacting and fomiatting of Java class files to more efficiently 

15 use memory. "Pre-intemalizatlon" is a process of reformatting 
Java class file Information Into a format that, when placed in 
memory, represents a class object. Internalization occurs 
during loading of a class file and is the process of extracting the 
class information from a class file and storing the information in 

20 structure(s) in dynamic memory. The pre-internalizatlon process 
eliminates symbolic references and class loading, reducing 
dynamic memory storage requirements and speeding up 
execution of the application. The format of the pre-intemaiized 
file is specific to each Java VM implementation. 

25 Pre-intemallzation occurs after compilation but prior to 

normal loading and execution of the JBC. Pre-intemalized class 
objects are restructured to eliminate the need to store them in 
dynamic memory, and can therefore be maintained in 
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permanent memory. This frees more of the dynamic memory 
for creation of dynamic objects during execution. Information 
and structures used to maintain state, as well as dynamic 
objects, are stored in what is referred to as the "Java heap". A 
S problem exists with pre-internalization as storing class 
Information in permanent memory eliminates the ability to 
update this information during execution. 

Current solutions avoid storing the symbolic information in 
dynamic memory by requiring that all symbolic references be 

10 resolved prior to dass Installation on the target device. 

Resolving references Involves replacing the reference with the 
location of the referenced item, i.e. an address. A problem 
exists in pre-internalizing a set of class files, or "class file unit," 
where a reference is made to classes already installed on the 

15 device and for whiph the location of the referenced Item Is either 
unlcnown or unreliable. To avoid duplicating the referenced 
class information, the installed classes are removed from the 
device and repackaged with the set of new files. 

Fig. 1 illustrates a prior art process 6 of processing 

20 program flies, also referred to as class files. Program flies 8, 
labeled "Class 1 "Class 2," and "Class 3," are loaded by 
preprocessor 10. Preprocessor 10 generates formatted class 
file information 12. The formatting converts each program file, 
Class 1 , Class 2, and Class 3, to class objects for use during 

25 execution, where the class objects are specific to the JVIVI 
implementation used. Preprocessor 1 0 is a tool that may be 
implemented in software or hardware. The formatted class file 
information 12 is structured for storage in a target device, where 
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the device has both dynamic and permanent memory. The 
compiler and linker 16 combines the formatted class file 
Information 12 with the Java VM source code 14. The Java VM 
source code 1 4 Is specific to the Java VM Implemented In the 
5 target device. The output of the compiler and linker 16 is the 
Java VM image 18, which has two portions: a first portion stores 
the Java VM 19; and a second portion stores preloaded class 
information 20. The preloaded class infomnatlon 20 Is the 
compiled version of the fonnatted class file informdtion. 

10 At this point, the Java VM image 1 8 is stored in device 

memory 22 of the target device. In this case, the device 
memory 22 Includes dynamic memory 26, and permanent 
memory 24. In one embodiment, the dynamic memory 26 is 
implemented with RAM and the pemianent memory 24 is 

15 implemented with ROM and/or Flash memory. The dynamic 
memory 26 is used during execution for storing interim values 
and variables. The permanent memory 24 includes multiple 
portions: a first portion 28 for storing a class loader; a second 
portion 30 for storing a JBC interpreter; and a third portion 32 for 

20 storing the preloaded class information 20. The class loader of 
portion 28 is used for formatting binary class information for use 
by the Java VM, and Is not required for preloaded class 
information 20, as they were formatted during preprocessing and 
compilation. The Java VM image 1 8 stored In the device 

25 memory 22 is used to run the Java program files, Class 1 , Class 
2, Class 3 in program files 8. The device memory 22 is then 
implemented within a device, such as a hand-held device or 
other application. 
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It is often desirable to delete program files from the 
permanent memory 24 after a manufacturer has performed 
process 6. Unfortunately, once class files d have been stored in 
the pemnanent memory 24, a user may not remove the stored 
5 program files without assistance from the manufacturer of the 
device. That assistance takes the form of either returning the 
device back to the manufacturer or receiving all the tools 
associated with process 6 from the manufacturer. 
Manufacturers are reluctant to release or license such 

10 proprietary tools to users. 

Furthermore, it is often desirable to add additional program 
files to the Java VM image in the device memory 22. Often the 
program files 8 describe basic functionality for an application, 
but the user is free to add supplemental functionality, such as 

15 user-specified or application-specific additions that enhance the 
device. There are several ways to add program files. In a first 
known process, the process 6 is performed again with the 
additional program files included with the program files 8. The 
resultant Java VM image 18 then includes the preloaded class 

20 information for all the program files, those in program files 8 plus 
the additional ones. This method is not flexible as the method 
requires either the user to return to the manufacturer to have the 
new program files included in the processing, or the method 
requires the manufacturer to provide the program files 8 to the 

25 user and allow the user to perform the processing. According to 
a second prior art method, illustrated in Fig. 2, additional 
program files 42, including program files labeled "Class 4, "Class 
5," and "Class 6," are stored in additional permanent memory 
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40, such as Flash memory. The program files 42 are then 
loaded by the class loader stored in portion 28 of permanent 
memory 24 into dynamic memory 26 on execution. The need to 
store the loaded program files, Class 4, Class 5, and Class 6, In 
5 dynamic memory 26 reduces the space available for the Java 
heap. The loss of dynamic memory space creates a situation 
where even if all the additional program files 42 are stored in 
dynamic memory 26, the remaining available dynamic memory 
space is insufficient to store variables during execution, i.e. the 

10 program cannot execute. Since dynamic memory space is 
typically limited, maximizing the amount of space available for 
the Java heap is crucial in many applications. 

Furthermore, the need to class load or Intemalize the 
additional program files 42 must be performed on every 

15 execution of the additional program files. In other words, the 
program files are not permanently internalized. Such 
applications are sometimes referred to as "transient 
applications." The repetitive internalization significantly slows 
execution of the program. It should also be noted that this 

20 process of internalization by a run time loader is not specific to 
the Java programming environment. 

Brief Description of the Drawings 
The present invention Is illustrated by way of example and 
25 not limited to the accompanying figures, in which like references 
indicate similar elements, and In which: 



wo 02/073401 



9 



PCT/USDl/49342 



FIG. 1 Illustrates in block diagram form a known method of 

processing program files for permanent storage in a device 
memory; 

FIG. 2 illustrates in block diagram form a known method of 
5 adding application-specific program files to a device memory as 
in FIG. 1; 

FIG. 3 illustrates in block diagram form a portable device 

for receiving a program file and creating an executable image of 

the program file in accordance with the present invention; 
10 FIG. 4 Illustrates in block diagram fomn details of the 

program file memory structure of the portable device of FIG. 3; 
FIG. 5 illustrates in flowchart form a process for creating 

and processing pre-internalized files in accordance with the 

present invention; 
15 FIG. 6 illustrates in flowchart form a process for off-client 

creation and processing of pre-internalized files in accordance 

with the present invention; 

FIG. 7 illustrates in block diagram form a client/off-client 

system for implementing the flowchart of FIG. 6; and 
20 FIG. 8 illustrates in block diagram form an embodiment of 

a device in accordance with the present invention. 

Skilled artisans appreciate that elements in the figures are 

Illustrated for simplicity and clarity and have not necessarily 

been drawn to scale. For example, the dimensions of some of 
25 the elements in the figures may be exaggerated relative to other 

elements to help improve the understanding of the embodiments 

of the present invention. 
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Detailed Description 

For ease of illustration, the Java programming language 
serves as an exemplar; however, the present Invention is 
5 applicable to other programming languages as well. Several 
terms will be used herein with reference to a system having 
embedded Java program(s). Memory refers to Read Only 
Memory (ROM), writable memory, and readable-writable 
memory. Readable-writable memory may be Random Acxjess 

10 Memory (RAM), Electrically-Erasable-Programmable Memory 
(EEPROM), Programmable Memory (PROM), including both 
One-Time PROM (OTPROM) and Erasable PROM (EPROM), 
Flash Memory, etc. The term "dynamic memory" is used to refer 
to memory that is dynamically allocated and does not retain 

15 stored Information or data when power is removed from the 
device, such as RAM. The term "permanent memory" is used to 
refer to memory that is treated as read-only during execution, 
and retains stored information or data when power is removed 
from the device, such as ROM. 

20 The present invention provides a method or process for 

creating and using pre-lntemallzed program flies written in a 
high level-language capable of dynamic loading. As used 
herein, the terms 'method' and 'process' are intended to be 
synonymous. A need exists for a method of processing program 

25 files that allows for the addition or removal of user-specific 
program files to improve subsequent execution speed of the 
additional program files without reducing the amount of dynamic 
memory available for execution. 
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illustrated in FIG. 3 is an exemplary programming 
environment 44 having a device 45 and additional program files 
46 having an arbitrary number of n class files, where n is an 
integer. Each class file is of arbitrary size and represents one of 
5 a collective set of program files that a user desires to add to 
device 45. It should be understood that the original 
manufacturer of device 45 did not program device 45 with the 
illustrated additional program flies 46. 

Device 45 is coupled to the additional program files 46 via 

10 an application manager 48. Bi-directionally coupled to 

application manager 48 is a dynamic memory 52, a pennanent 
memory 56 and a Virtual Machine (VM) 50. One form of 
dynamic memory 52 is a random access memory (RAM), and 
pennanent memory 56 may be implemented as a Flash 

15 memory. Permanent memory 56 stores the pre-intemalized 
image of additional files 46. In the illustrated fomi, Virtual 
Machine 50 is separately coupled to each of dynamic memory 
52 and permanent memory 56. It should be well understood that 
information Is transferred within device 45 between dynamic 

20 memory 52 and pennanent memory 56 via conductors that are 
not illustrated in response to the Virtual Machine 50. In the 
illustrated form, Virtual Machine 50 has a class loader 61, a 
class resolver 62, a class verifier 63, a resource manager 64, a 
dynamic memory manager 65, a byte code interpreter 66, a pre- 

25 intemallzer 67, and a plurality of preloaded applications and 
libraries 68 all of which reside in permanent memory 69. The 
Virtual Machine 50 also has a Java Heap 54 that resides in 
dynamic memory 70. 
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In operation, device 45 was originally programmed by a 
manufacturer to have predetermined program files that are 
contained within the preloaded applications and libraries 68. 
When such preloaded applications are executed, the Virtual 
5 Machine 50 executes in a first or nonnal mode and processes 
the applications out of Its pemnanent memory 69. Assume 
however that a user of device 45 desires to add additional files 
46 from any source external to the device 45. The application 
manager 48 functions to assist with placement of the additional 

10 files 46 In either dynamic memory 52 or permanent memory 56. 
The choice of which memory Is used is application specific and 
not germane to the present invention. Application manager 48 
starts Virtual Machine 50 in a second or pre-internalization mode 
that will pre-internalize the program files into the Virtual 

IS Machine's native memory structure. For purposes of 

clarification, the temn 'native memory structure' used herein shall 
mean that the operation is specific to the particular Virtual 
Machine being discussed as opposed to any other Virtual 
Machine. A native memory structure refers to a particular Virtual 

20 Machine where that Virtual Machine is a particular instantiation 
of that Virtual Machine on the device. The result of the pre- 
Internallzation mode is a pre-internalized image of the program 
files that is then stored in pennanent memory 56. This pre- 
internalized image is a reusable executable irriage since the pre- 

25 internalized image Is now resident In permanent memory, and, 
should the newly Introduced application need to be executed 
subsequently, the pre-internalization does not need to be 
repeated. Furthermore, the original copy of the additional files 
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46 placed Into dynamic memory 52 or permanent memory 56 
can now be deleted, resulting in significant memory savings. 

The Virtual Machine 50 is a standard virtual machine that 
has been modified in order to be able to perfonm the pre- 
5 internalization function. Prior virtual machines do not perfomi 
pre-lnternallzatlon. The class loader 61 and class resdver 62 
have been modified to execute in either normal mode or pre- 
internalization mode. Furthermore, the class loader 61 has been 
extended to recognize pre-lnternaiized classes. The byte code 

10 interpreter 66 has been extended to support new byte codes 
created by the pre-intemallzer 67. 

For purposes of clarity, the process of pre-internallzation 
involves the processing of class files. Initially classes are 
brought into the Virtual Machine 50 by the class loader 61 . 

15 Class loader 61 creates Virtual Machine-specific data structures 
associated with each and every class of the additional program 
files 46. In normal mode, classes are loaded by the class loader 
61 as determined by application usage. During pre- 
Internaiization, the Virtual Machine-specific data structures are 

20 scanned to detenmine what other classes, either internal or 
external to the additional files, are referenced during execution 
of the additional classes. In normal mode, class initialization 
methods may need to be executed during class loading, hence 
requiring the invocation of the byte code interpreter 66. Byte 

25 code interpreter 66 performs any initialization that is specific to a 
predetemilned class. Such classes include, for example, static 
initializers. During pre-internalization for the purposes of 
Installation, execution of the static initializers is not performed. 
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Execution of the static initializers only occurs if the application is 
being executed. The class resolver 62 of Virtual Machine 50 Is 
used to resolve entries in each class's constant pool in a 
conventional manner consistent with the published Java 
5 reference platfonn. Upon completion of the resolution, the Java 
ByteCode (JBC) are updated to point to the now resolved 
references (via address pointers). Furthermore, the classes are 
verified in a conventional manner by the class verifier 63 of 
Virtual Machine 50 during pre-lnternalization. The verification of 

1 0 classes is eliminated for future execution of the additional files. 
Verification is a conventional function in the Java programming 
language and further discussion of the verification will not be 
provided. The resource manager 64 stores the resources 
associated with the additional files in a manner so that the 

15 resources are associated with the additional program files. The 
dynamic memory manager 65 is used throughout the process to 
create the data structures associated with the class in dynamic 
memory. The resultant data structures collectively are referred 
to as an Internalized image. The final Image is then written to 

20 permanent memory 56. In summary, the pre-lntemalizer 67 is a 
thin piece of code that directs the components of Virtual 
Machine 50 to perform these pre-internalization steps. 

Illustrated in FIG. 4 is a further detail of the permanent 
memory of FIG. 3 after the pre-internalization of two program 

25 files. A plurality of program files 73, including a third set of 
program files 74, is coupled to a Java Application Manager 
(JAM) 76. The JAM 76 maintains a list of dynamically pre- 
Internallzed applications In a permanent memory 92. The pre- 
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Internalized applications are refen^ed to as being "dynamic" in 
the sense that the applications are added to the Virtual Machine 
after manufacturing and sale of the Virtual Machine has 
occurred. 

5 The JAM 76 is connected to a Virtual Machine 72 having 

the same components as Virtual Machine 50 of FIG. 3. For 
convenience of illustration, not all components of a virtual 
machine are expressly detailed in FIG. 4. The Virtual Machine 
72 has a byte code Interpreter 79 for use when the VM is in a 

10 first or normal mode of execution, a pre-lntemallzer 80 for use 
when the VM Is In a second or pre-lnternallzatlon mode of 
execution, and preloaded classes 81 of program files. The 
Virtual Machine 72 is coupled to a permanent memory 84 
containing a pre-internalized Image 86 of a first set of program 

15 files, a pre-lnternallzed Image 88 of a second set of program 
files, and space for future program files 90. 

In operation, the JAM 76 directs the Virtual Machine 72 to 
execute preloaded classes 81 and/or pre-internalized image 86 
and/or pre-lnternalized image 88 when operating In the first or 

20 normal mode primarily using its byte code Interpreter 79. Jam 
76 directs Virtual Machine 72 to pre-lnternalize the third set of 
program files 74 by primarily using its pre-internalizer 80. Pre- 
internalizer 80 functions to implement the pre-internalization of 
the third set of program files 74 in a same manner as described 

25 In connection with pre-lnternallzer 67 of FIG. 3. Pre-lnternallzer 
80 creates an Image for the third set of program files 74 that is 
then stored In the space for future program files 90. Additionally, 
the Jam 76 directs Virtual machine 72 to remove the second set 
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of program files 88 from the permanent memory 84. Jam 76 
maintains knowledge of pre-internalized images through the use 
of a list of dynamically pre-internalized applications kept In 
penmanent memory 92. Before pre-lnternalizing a set of 
5 program files, the Jam 76 obtains the amount of space for future 
program files 90 from the Virtual Machine 72 operating in the 
second mode. This assists the JAM 76 in determining if a 
program file set can be pre-internalized. The Virtual Machine 72 
operating in the second mode also retums its success or fail 
10 Indication to the JAM 76 after a request for adding a set of 

program files 74 or removing the already pre-internalized image 
88. 

It should be noted in both of the embodiments illustrated in 
FIG. 3 and FIG. 4 that the virtual machine's core components 

15 are being reused by the second mode or pre-intemalization 
mode. As a result, the virtual machine is enhanced in the 
present invention to permit storage of Images that have been 
fully translated to a memory resource address. 

Illustrated in FIG. 5 is a process 100 illustrating a variety of 

20 program application execution options for a Java application 
manager in association with a Virtual Machine. The process 
begins with a start step 101 . in step 103 either a user or another 
source selects a program file from a set of available program 
files. The selected program files may or may not already be 

25 present in memory on the device in a pre-lntemallzed image 
form. The set contains preloaded classes and/or pre- 
internalized images and/or program files external to the Virtual 
Machine, it should be understood that the processing of 
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preloaded classes is not detailed in FIG. 5. In a step 105, a 
determination is made as to whettier a pre-internalized 
application image has been previously created. If previously 
created, the Image would be resident in permanent merhory on 
5 the device containing the Virtual Machine, if the resulting 

answer to step 1 05 is Ves', a step 1 07 provides two choices: (1 ) 
run the program files; or (2) to remove the program files from the 
pre-internalization space of permanent memory, in one form, a 
user request may be received from a user to elect which choice 

10 to make. Assume initially that either the user or other source 
elects to run the program files. Since the program files exist in 
the pre-internalization space of permanent memory, the Virtual 
IVIachine in normal mode is called by the Java application 
manager to execute the pre-internalized image in a step 1 09. 

15 Upon completion of execution, an end step 1 00 has been 
reached with respect to execution of the program file. Assume 
that the user or other source elects to remove the program file 
from permanent memory of the device containing the Virtual 
l\/lachine. The Java application manager calls the Virtual 

20 Machine in the second mode to remove the pre-internalized 
image in a step 112. It should be noted that the removal of pre- 
internalized Images is an additional function of the pre- 
Internalizer when the Virtual Machine is operating in the pre- 
internalization mode. Upon removal, an end step 1 13 is 

25 reached. The Java application manager will also update the list 
of dynamically pre-internalized program files in permanent 
memory. 
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Returning to step 105, assume that no pre-lntemalizatlon 
image of Interest has previously occurred. If the resulting 
answer to step 105 is 'no', a step 1 14 provides two choices: (1) 
run the program files; or (2) add the program files to the pre- 
5 internalization space of penmanent memory. In one 

implementation, the choice may be implemented In response to 
a user request to either run the program files or to enter the pre- 
internalization mode. Another embodiment may implement the 
choice with an automatic run routine. If a decision to run the 

10 program files is made by the user or other source, a step 11 6 is 
perfomned. It should be noted that the step 1 16 Is consistent 
with execution of a non-pre-intemalized program files that would 
be performed by the device in FIG 2. Step 1 1 6 has a first step 
1 18 In which the program files are internalized by the Virtual 

15 Machine when operating in the first or normal mode. Note that 
the pre-intemalizer of the Virtual Machine is not used for this 
pre-internallzation function. Rather, the Virtual Machine uses 
the various functional portions, such as the verifier, the resolver, 
etc., to perform the pre-lntemalization. in a step 120 the Virtual 

20 Machine executes the program files after internalization has 
occurred in step 1 18. A step 121 ends the execution of the 
program. It should be noted that because the program was not 
a stored pre-internalized image, the step 1 18 has to be 
performed every time that the program files are selected for 

25 execution. Returning to step 114, should the user or other 
source elect to pre-lntemalize the program files, a step 124 Is 
performed rather than step 116. in step 124, the Java 
application manager calls the Virtual Machine in the second or 
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pre-rntemallzation mode to create a pre-intemalized image in the 
manner described above for FIG. 3. Upon creation of tlie pre- 
internalized image, tlie image is stored in permanent memory of 
the device. It should be noted that step 124 does not need to be 
5 performed again should the program files be selected again for 
execution as step 105 would thereafter direct the process to step 
107. 

Illustrated in FIG. 6 is an alternate embodiment process 
130. Process 130 begins with a step 131. In a step 133, a user 

10 or other source selects one or more program files from a set of 
available program files. In one form, possible 'other sources' for 
this selection may include an off-device program file server or 
another off-device source. In a step 135, a decision is made as 
to whether a pre-intemalized image has been created on the 

15 device. The reason the 'on the device' criteria has been added 
to step 135 is because this embodiment Illustrates the situation 
of receiving an already pre-intemalized image from an off-device 
source and how the pre-internalizer handles that case. If the 
answer is 'yes', then steps 137, 140, 141, 143 and 144 are 

20 exactly the same as steps 1 07, 1 09, 1 00, 1 1 2 and 1 1 3 of FIG. 5, 
respectively. Step 137 may be determined In response to a user 
request to either perform a run or a remove operation. If the 
answer is 'no', a step 146 is executed where a decision is made 
as to whether a pre-intemalized image has been created 

25 elsewhere for the device. If the answer to this query is 'no', 
steps 148, 150, 151, 152, 153, 156 and 158 are exactly the 
same as steps 1 14, 1 1 6, 1 1 8, 1 20, 1 21 , 1 24 and 1 25 of FiG. 5, 
respectively. Step 148 may be determined in response to a user 
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request to efther perform a run or a pre-internalize operation. If 
the answer to this query is 'yes', a step 157 is implemented. In 
step 157 the Virtual IVIachine is called by the Java Application 
Manager to not pre-internalize the Image, but rather to only to 
5 copy and patch the pre-lnternalized Image to a specific location 
In the device's permanent memory. Upon completion of step 
157, an end step 160 is reached. 

Reference to FIG. 7 will further illustrate the processing of 
Images received from off-device sources. This embodiment 

10 addresses the need to further reduce the execution time of an 
application by significantly reducing the pre-lnstallation time. In 
other words, the present invention may be implemented on a 
device that functions as a server. Therefore, advantage is made 
of running the Java Virtual Machine environment on an off- 

15 device server or on an off-device client (peer-to-peer) that Is 
similar to the existing device. The difference from an off-device 
image and an image created by the device's Virtual Machine is 
where the image is stored within the device's memory resources. 
A system 180 generally has a first client device 182, a 

20 second client device or server with client device simulation 181 
and an application suite 184 that Is not resident In a reusable 
executable image fonn on device 182. Client device 182 
generally comprises an application manager 204, a dynamic 
memory 206, a permanent memory 220 and a virtual machine 

25 210. In one fonn, the structure of devices 1 81 and 1 82 is the 
same as device 45 of FIG. 3. It should be apparent that 
alternate embodiments and modified structure could be created 
to perform the functionality taught herein. An optional storage 
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device 200 In permanent memory outside of device 182 may be 
used to store pre-internalized images of additional files. 

In operation, the additional files 184 are created by a 
source external to devices 181 and 182. The additional files 184 
5 are brouglit into device or server with client device simulation 
181 by its application manager 185. The additional files are pre- 
internalized into its penmanent memory 190 by the Virtual 
Machine 1 88 operating in the second mode. Virtual Machine 
188 utilizes dynamic memory 187 to support this mode. The 

10 stored image may or may not be executed by device 181 . If 
device 181 is a client device, then it is likely that this application 
Image will be executed by device 181 . If device 181 is a server 
with client device simulation, then device 181 Is used merely to 
create the pre-internalized image (i.e. device 181 functions as 

15 an application server). When device 181 is used as a server 
with client device simulation, the image is optionally stored in 
permanent memory 200 which can be located anywhere within 
system design choice. When application manager 204 of the 
first client device 182 receives the pre-internalized image from 

20 pemnanent memory 200 or from the application manager 1 85, 
then only the last step of pre-internalization must occur. The last 
step is step 157 of FIG. 6 and involves a copy and patch of the 
pre-internalized image to permanent memory 220. Therefore, it 
should be apparent that system 180 functions to enable device 

25 1 82 to avoid the full pre-internalization processing steps. With 
low-end client devices that are extremely limited in processing 
power and dynamic memory size, the present invention enables 
low-end client devices to be capable to be configured with non- 
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resident applications as compared to a stand-alone device. 
Additionally, the low-end client configuration taught herein is fast 
as compared to prior devices that perform the entire pre- 
intemaiization process every time a non-intemallzed program 
5 requires execution. 

Illustrated in FIG. 8 Is a device 300 that implements the 
present invention. Device 300 has a processor 302 and a 
memory 304. Memory 304 may be organized to have many 
different structures and FIG. 8 only illustrates a structure similar 

10 to that discussed in connection with the prior figures. An I/O is 
bi-directionally coupled to processor 302 and memory 304 which 
are also bi-directionally coupled. In the illustrated form memory 
304 has a Java Application Manager 310, a Virtual Machine 312, 
a Dynamic Memory 314 and a permanent memory 316. 

15 in operation, the processor executes predetennined 

Instructions. A first portion of memory 304 is coupled to 
processor 302 for providing Instructions and data to the 
processor. In one form, the first portion of memory 304 is the 
Virtual Machine 312. Memory 304 contains at least a first,, a 

20 second and a third set of one or more instructions. Whether 
each set of the instruction sets to be discussed contains one or 
a plurality of instructions Is a matter of design and programming 
choice and depends upon how much hardware functionality is 
desired versus software functionality. Solely for purposes of 

25 discussion, an assumption will be made in the following 

discussion regarding instruction functionality that a plurality of 
instructions will be used in order to minimize the hardware 
implementation. However, the instruction functionality to be 
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described herein may be implemented witli a single instruction if 
desired. The first plurality of instructions is for receiving a first 
program file. The second plurality of instmctions is for pre- 
internalizing the first program file into the Virtual Machine's 
5 native memory structure to create a reusable executable image 
of the first program file. The third plurality of instructions is for 
storing the pre-intemalized program file image or reusable 
executable image in a second memory portion within memory 
304. The reusable executable Image is capable of being 

10 executed by the Virtual IVIachine 312 without being intemalized 
prior to execution. 

Memory 304 of FIG. 8 may also include a fourth plurality of 
instructions for receiving and storing a reusable executable 
image in the memory. When the reusable executable image is 

15 stored, memory pointers are updated by a built-in mechanism to 
permit the images to be moved around within the same device 
memory. Therefore, the memory which stores reusable 
executable images is capable of dynamic memory reconciliation 
to effectively use memory storage and reconcile memory to 

20 efficiently use available addresses. This process permits 

objects to be moved on the device to create a second reusable 
executable image. After a reusable executable image is stored 
within a device, the memory addresses within the reusable 
executable Image(s) are updated to reflect its present memory 

25 address. Memory 304 may also include a separate plurality of 
instructions which is executed when processing a user request 
wherein in response to the user request the virtual machine 
operates in the pre-internalization mode. A separate plurality of 
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Instructions may be In memory 304 for causing the transfer of 
the pre-internalized program file image from a second memory 
which may be either within or external to the device. Another 
plurality of Instructions within memory 304 may Implement the 
S processing of a user request by either moving or totally 
removing a pre-intemalized program file from memory. 

The reusable executable image was previously created by 
pre-internallzing a program file into the Virtual IVIachine 31 2's 
native memory structure. In such an instantiation, the Virtual 

10 Machine 31 2 is capable of executing the reusable executable 
image without internalizing the reusable executable image prior 
to execution. The memory 304 may additionally store a 
separate plurality of instructions for moving the reusable 
executable image to a different location within the memory. 

15 Further, memory 304 may store another set of instructions that 
are capable of updating memory addresses within the reusable 
executable image or pre-internalized program file image. It 
should be understood that memory 304 also may store 
instructions which implement the process of each of FIG. 5 and 

20 FIG. 6. 

The present Invention Is particularly advantageous to use 
in portable, wireless devices. Examples of the type of portable 
device that could implement the present invention include a 
diverse group such as a telephone, an internet appliance 
25 (portable and/or non-portable), a personal digital assistant 
(PDA), a pager, a camera, a camcorder (camera/recorder), a 
portable television, and products that combine various 
communication functions. 
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In the foregoing specification, the invention has been 
described with reference to Java programming language and 
specific embodiments. However, one of ordinary sl<i]l in tfie art 
appreciates that various modifications and changes can be 
5 made without departing from the scope of the present invention 
as set forth in the claims below. For example, the present 
invention is applicable to other high-level programming 
languages that enable dynamic loading. Also, the software 
taught herein (such as a software implementation of the Virtual 

10 Machine 50 of FIG. 3, for example) may be embodied on one or 
more of computer hard disl^s, floppy disks, 3.5" disks, computer 
storage tapes, magnetic drums, static random access memory 
(SRAi\/l) cells, dynamic random access memory (DRAI\^) cells, 
electrically erasable (EEPROM, EPROM, Flash) cells, 

15 nonvolatile cells, ferroelectric or ferromagnetic memory, compact 
disks (CDs), laser disks, optical disks, and any like computer 
readable media. Accordingly, the specification and figures are 
to be regarded in an illustrative rather than a restrictive sense, 
and all such modifications are Intended to be included within the 

20 scope of present Invention. 

Benefits, other advantages, and solutions to problems 
have been described above with regard to specific 
embodiments, i-iowever, the benefits, advantages, solutions to 
problems, and any element(s) that may cause any benefit, 

25 advantage, or solution to occur or become more pronounced are 
not to be construed as a critical, required, or essential feature or 
element of any or all the claims. As used herein, the terms 
"comprises," "comprising," or any other variation thereof, are 
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intended to cover a non-exclusive Inclusion, such that a process, 
method, article, or apparatus that comprises a list of elements 
does not include only those elements but may include other 
elements not expressly listed or Inherent to such process, 
5 method, article, or apparatus. 
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CLAIMS 

1 . A process for operating a virtual machine having a normal 
mode of operation and a pre-intemalizatlon mode of 

5 operation, comprising: 

selecting a program file from a set of available 

program files to identify a selected program file; 
determining whether a reusable pre-internalized 
image of the selected program file has been 
10 created, wherein the reusable pre-intemalized 

image is capable of being executed without 
subsequently internalizing the selected program 
file prior to execution; 
if a reusable pre-lntemallzed Image of the selected 
15 program file has not been created, selectively 

operating the virtual machine in the pre- 
internalization mode, comprising: 
creating the reusable pre-internallzed image of 
the selected program file; and 
20 storing the reusable pre-lntemalized image of 

the selected program file into memory. 

2. The process of claim 1 further comprising: 

If a reusable pre-lntemalized image of the selected 
25 program file has not been created, selectively 

operating the virtual machine in the pre- 
internallzation mode is performed in response to 
a user request. 
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3. The process of claim 1 wherein the virtual machine executes 
within a first device and the process further comprises: 

if the reusable pre-intemalized image of the selected 
5 program file is available within the first device, 

executing the reusable pre-internalized image of 
the selected program file without internalizing 
the reusable pre-internalized image of the 
selected program file prior to execution, and 
10 if the r^sable pre-internalized image of the selected 

program file is available within a second device, 
separate from the first device, entering the pre- 
internalization mode, copying the reusable pre- 
internalized Image of the selected program file 
15 from the second device to the first device, and 

updating memory addresses within the reusable 
pre-internalized image of the selected program 
file. 



20 4. The process of claim 1 further comprising: 

executing the virtual machine within a first device; 
and 

if the reusable pre-intemalized image of the selected 
program file is available within the first device, 
25 selectively entering the pre-lntemalizatlon mode 

and removing the reusable pre-internalized 
image of the selected program file. 
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5. A device comprising: 

a processor for executing instructions; 
a first memory coupled to tlie processor for providing 
Instructions and data to the processor, the first 
5 memory comprising: 

a first set of one or more Instmctlons, the first set of 
one or more Instructions when executed by the 
processor implements receipt of a program file; 
a second set of one or more Instructions, the second 
10 set of one or more Instructions when executed 

by the processor implements pre-intemalizing 
the program file into a native memory structure 
of a virtual machine to create a reusable 
executable image of the program file; and 
1 5 a third set of one or more Instructions, the third set of 

one or more Instructions when executed by the 
processor implements storing the reusable 
executable image, wherein the reusable 
executable image is capable of being executed 
20 by the virtual machine without being Internalized 

prior to execution. 
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6. The device of claim 5 furtlier comprising a second mennory 

either contained witiiin the device or external to the device 
and wherein one of the first memory or the second memory 
comprises a fourth plurality of instructions, the fourth set of 
one or more instructions updating a memory address within 
the reusable executable image when executed by the 
processor. 

7. The device of claim 6 further comprising a second memory 

either contained within the device or extemal to the device 
and wherein one of the first memory or the second memory 

comprises: 

a fourth set of one or more instructions, the fourth set of 
one or more instructions when executed by the 
processor moving the reusable executable image to a 
different location within the second memory; and 

a fifth set of one or more Instructions, the fifth set of one or 
more instructions when executed by the processor 
updating memory address within the reusable 
executable image. 
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